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Evaluation 


1.  This  effort,  entitled  "Automated  Code  Generators  for 
Compilers"  Is  an  attempt  to  produce  a Quick  Code  Generator  (QCG) 
for  an  Interim  compiler  which  will  permit  the  use  of  this 
compiler  until  a permanent,  more  efficient  code  generator  is 
developed.  The  output  of  the  QCG  Is  assembly  language  for  the 
target  machine  rather  than  the  object  code  normally  associated 
with  code  generators.  RADC's  JOCIT  JOVIAL  Compiler  was  the 
subject  of  this  effort  and  the  approach  taken  was  to  replace 
the  JOCIT  Code  Generator  and  Editor  with  a QCG  and  Macro 
Assembler  (MAS),  respectively.  Communication  between  these 
two  phases  was  accomplished  via  the  macro  language,  MIMIC. 

MIMIC  is  an  acronym  for  Machine  Independent  Macro  Instruction 
Code  and  Is  a generalized  assembly-type  language,  designed 
to  easily  map  Into  most  existing  assembly  languages.  The  user 
Is  required  to  write  a Macro  Definition  File  (MDF ) that  is  to 
Interface  with  MIMIC. 


2.  This  effort  was  successful  In  developing  a QCG  for  JOCIT 
for  the  HIS  6000  Series,  but  several  problems  are  still  to 
be  resolved.  Mainly,  the  QCG  will  not  operate  with  the  JOCIT 
Optimizer,  nor  will  the  compiler  function  correctly  If  a 
cross-reference  listing  Is  requested  or  the  DIRECT  Code  Option 
Is  used.  Problems  still  exist  with  Internal  data  representations, 
but  It  should  be  noted  that  tests  comparing  the  original  JOCIT 
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JOVIAL  Compiler  and  the  QCG  JOCIT  Compiler  revealed  the  difference 
In  compilation  time,  execution  time  and  total  code  produced 
was  Insignificant. 

RICHARD  M.  MOTTO 
Project  Engineer 


iv 


INTRODUCTION  AND  SUMMARY 


The  "Automated  Code  Generators  for  Compilers"  contract  F30602-76-C-042 9 was 
begun  in  September,  1976.  It  was  one  of  a series  of  contracts  to  provide  the  Air 
Force  with  an  advanced  JOVIAL  (J3)  compiler  capability.  Earlier  contracts  have 
resulted  in  a system  called  JOCIT  which  is  an  acronym  for  JOVIAL  Compiler  Imple- 
mentation Tool.  JOCIT  consists  of  a JOVIAL  compiler,  a SYMPL  compiler, 

GENESIS  processor  and  an  executive  which  interfaces  with  the  host  operating  system 
(in  this  case,  Honeywell  6000  GCOS).  Most  of  the  modules  of  the  JOVIAL  compiler 
and  the  SYMPL  compiler  are  written  in  the  SYMPL  language.  SYMPL  is  a procedure- 
oriented  programming  language  whose  emphasis  is  on  ease  of  expression  of  "System" 
programs.  SYMPL  is  in  many  ways  similar  to  both  FORTRAN  and  JOVIAL.  GENESIS 
is  a Computer  Sciences  Corporation  proprietary  system  for  producing  language  syntax 
tables  suitable  for  use  in  certain  types  of  syntax-directed  compilers  from  a convenient 
syntax  description  language. 

The  primary  purpose  of  this  contract  was  to  further  automate  the  task  of  producing 
a JOCIT-built  compiler  code  generator.  There  was  no  expectation  that  the  code 
generator  produced  by  this  effort  would  equal  the  quality  or  efficiency  of  the  code 
generators  produced  by  an  experienced  compiler  writer.  However,  if  the  result 
of  this  effort  could  rigidly  and  inexpensively  produce  a code  generator  of  acceptable 
(not  defined)  quality,  then  a significant  advance  would  be  made  to  the  state-of-the- 
art.  The  code  generators  thus  produced  would  presumably  be  used  temporarily  in 
new  operational  environments  until  a more  permanent,  efficient  code  generator  was 
written  for  the  particular  target  computer. 

A number  of  approaches  were  investigated,  but  the  final  design  consisted  of  the 
"code  generator"  producing  macros  for  an  assumed  very  basic  computer.  For 
example,  the  computer  was  assumed  to  have  one  accumulator,  one  index  register, 
one  single  precision  floating  point  register,  etc.  The  macro  code  file  thus  gen- 
erated is  machine  independent  or  nearly  so.  This  macro  code  file  is  then  processed 
by  the  "macro  assembler"  which  essentially  takes  the  place  of  the  editor  in  a con- 
ventional compiler.  The  "macro  assembler"  itself  is  also  machine  independent 
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but  accesses  a machine-dependent  "macro  definition  file".  Each  new  target  machine 
requires  the  production  of  its  macro-definition  file. 

The  macro  definition  file  essentially  defines  each  of  the  macros  which  can  be  pro- 
duced by  the  "code  generator"  in  terms  of  assembly  language  attributes  of  the  tar- 
get machine.  The  macro  assembler,  then,  as  it  processes  the  macro  code  file, 
produces  a new  output  file  of  a target  machine  assembly  language  program.  This 
assembly  language  program  can  then  be  assembled  on  the  target  machine  to  produce 
object  code  for  execution. 

Therefore,  in  order  to  produce  a new  "code  generator"  for  a target  machine,  an 
individual  would  have  to  have  a good  working  knowledge  of  the  assembly  language  of 
the  target  machine  and  the  purpose  for  each  of  the  macros  that  are  possible.  Cur- 
rently, the  "code  generator"  can  produce  approximately  113  macros.  However, 
many  are  similar  in  nature  and  would  require  only  minimal  changes  in  their  defini- 
tions. 

The  final  result  of  this  contract  is  a working  "quick  code  generator".  A macro 
definition  file  for  the  Honeywell  6000  series  computer  was  written  and  several  test 
programs  were  run  through  the  new  code  generator.  Assembly  language  programs 
were  produced  and  subsequently  assembled  by  the  GMAP  assembler  at  RADC  and 
executed.  There  was  not  sufficient  time  to  generate  macro  definition  files  for 
other  possible  target  machines.  However,  it  is  believed  that  a person  familar  with 
a target  machine  and  some  study  of  the  Automated  Code  Generator  User  Manual 
could  produce  a macro  definition  file  in  less  than  three  months. 

The  "quick  code  generator"  was  integrated  into  JOCIT,  so  that  one  JOVIAL  com- 
piler can  use  either  the  "quick"  or  the  "normal"  code  generator.  This  is  accom- 
plished by  the  use  or  non-use  of  the  QUICK  option  in  the  JOVIAL  control  card.  It 
is  also  possible  to  select  four  different  macro  definition  files,  if  they  are  available, 
to  produce  code  for  different  target  machines. 

In  order  to  complete  a working  version  of  the  new  code  generator  in  the  time  avail- 
able, a number  of  features  permitted  with  the  normal  code  generator  are  not  possi- 
ble currently  with  the  "quick"  code  generator.  These  include  "direct  code"  and 
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global  optimizations.  Furthermore,  the  cross-reference  capability  cannot  be 
correctly  executed.  During  the  course  of  this  contract  a parallel  effort  was  per- 
formed on  JOCIT  to  add  double  precision  capability.  This  complicated  the  effort 
on  the  "quick"  code  generator,  but  the  double  precision  capability  is  operational 
now  for  the  "quick"  option  as  well. 


AUTOMATED  CODE  GENERATORS  FOR  COMPILERS 


The  purpose  of  the  JOCIT  Automated  Code  Generator  (ACG)  is  to  help  automate  the 
retargeting  of  the  JOCIT  compiler.  The  ACG  provides  a means  for  the  rapid  develop- 
ment of  a new  compiler  "back  end",  producing  code  for  a desired  target  machine. 

The  goal  is  to  make  a compilation  facility  available  early,  so  that  a user  considering 
the  use  of  the  JOVIAL  High  Order  Language  (HOL)  will  not  have  to  wait  up  to  a year 
for  the  handcrafting  of  a code  generator  to  fit  his  needs.  If  a high  degree  of  code 
efticiency  is  important,  then  a special  code  generator  has  to  be  constructed,  but  at 
least  a coding  and  checkout  environment  will  be  available  through  the  ACG  several 
months  before  the  final  code  generator  is  ready. 

The  first  design  decision  made  for  the  ACG  was  to  output  assembly  language  code 
for  the  target  machine's  assembler,  rather  than  to  produce  binary  code.  The  reason 
for  this  decision  was  the  elimination  of  the  target  machine's  relocatable  format  and 
linker  requirements  from  consideration  in  the  retargeting  effort,  as  well  as  internal 
instruction  and  data  representations. 

STRUCTURE  OF  THE  ACG 

Structurally,  the  ACG  consists  of  (1)  a modified  version  of  the  Code  Generator  phase, 
called  the  Quick  Code  Generator  (QCG),  (2)  a new  phase  in  lieu  of  the  Editor  phase, 
called  the  Macro  Assembler  (MAS),  and  (3)  a group  of  procedures  supplied  by  the 
retargettor,  called  the  Macro  Defirition  File  (MDF). 

QUICK  CODE  GENERATOR 

Providing  a suitable  set  of  MDF  procedures  is  the  principal  effort  of  retargetting; 
each  of  these  procedures  has  a specified  task  in  the  production  of  the  assembly  code 
output.  In  determining  what  these  tasks  should  be,  many  computers  and  their  assem- 
bly languages  were  studied.  Among  the  architectural  features  considered  were 
addressibility,  register  usage,  word  sizes,  and  alignment  requirements.  Assembler 
considerations  included  formats,  naming  conventions,  special  features,  pseudo-ops, 
etc.  The  result  of  these  studies  was  the  MIMIC  (Machine  Independent  Macro  Instruo- 
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tion  Code)  "language",  which  drives  the  generation  of  the  output  assembly  code. 

MIMIC  is  the  internal  language  (IL)  form  of  the  program  produced  as  output  by  the 
QCG.  Essentially,  it  is  "machine  code"  for  a hypothetical  and  very  simple  computer. 
The  architecture  of  the  MIMIC  computer  has  been  carefully  chosen  to  avoid  present- 
ing any  impossible  situations  in  representing  its  functions  on  a real  computer.  The 
MIMIC  machine  has  the  following  characteristics: 

• Single  address  instruction  format 

• One  fixed  point  or  integer  accumulator  register 

• One  single  precision  floating  point  accumulator  register 

• One  double  precision  floating  point  accumulator  register 

• One  index  register 

• Access  to  all  types  of  data 

• Arithmetic  operations  in  integer,  single  floating,  and  double 
floating  modes 

• Comparisions  in  integer,  single  floating,  and  double  floating 
modes 

• Full  word  addressing  with  optional  index  register  address 
modification 

• Although  different  MIMIC  instructions  are  used  to  load  each 
of  the  three  accumulator  registers,  the  QCG  assumes  that 
these  registers  overlap,  so  that  a load  of  any  one  of  them 
destroys  the  contents  of  the  others. 

The  full  MIMIC  language  is  documented  elsewhere,  but  an  example, is  appropriate 
here.  A simple  JOVIAL  replacement  statement  might  produce  the  following  sequence 
of  MIMIC  instructions: 
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LOAD 

operand  AA 

(Load  the  integer  accumulator) 

SCLL 

2 

(Scale  left  by  2) 

ADDI 

operand  BE 

(Add  to  the  integer  accumulator) 

STORE 

operand  CC 

(Store  the  integer  accumulator) 

The  QCG  generates  into  the  Code  File  a sequence  of  MIMIC  instructions  represent- 
ing the  executable  part  of  the  source  program,  together  with  MIMIC  pseudo-ops 
declaring  data  reservations,  external  references  and  definitions,  etc. , obtained 
by  scanning  the  JOCIT  Symbol  Table. 

The  task  of  the  retargettor  is  to  determine,  for  each  MIMIC  "macro"  (instruction 
or  pseudo-op),  what  lines  of  assembly  code  should  be  produced  for  the  target  machine. 
This  includes  the  related  design  tasks  of  determining  how  to  use  the  target  machine's 
registers,  what  linkage  conventions  will  be  followed  in  procedure  calls,  how  the 
target  machine  assembler's  location  counters  will  be  used,  etc.  Then  the  user 
must  supply,  in  the  MDF  module,  a procedure  entry  point  for  each  MIMIC  macro. 

An  early  design  decision  was  made  to  have  these  MDF  procedures  coded  in  SYMPL. 
The  alternative  was  to  provide  a new  language,  with  a preprocessor  to  convert  the 
new  language  into  an  interpretable  form.  A new  language  was  indeed  designed  and 
studied,  but  was  rejected  on  two  grounds.  First,  its  advantages  over  SYMPL  as  a 
coding  language  were  not  felt  to  be  striking  enough  to  justify  the  effort  and  expense 
of  producing  an  additional  processor  and  interpreter.  Second,  it  was  a less  power- 
ful language  than  SYMPL,  and  it  was  not  clear  that  anything  less  powerful  than  a 
full  algorithmic  language  could  be  guaranteed  to  solve  any  unforseen  problems 
which  might  arise  in  a specific  retargetting  effort.  Using  SYMPL,  the  MDF  pro- 
grammer is  free  to  have  global  variables  which  pass  information  from  one  MIMIC 
macro  procedure  to  another,  as  well  as  lower-level  procedures  for  common  functions. 

In  deciding  how  to  implement  the  Quick  Code  Generator  (QCG) , several  alternative 
approaches  were  considered  for  various  aspects  of  the  design.  The  first,  and 
most  critical  alternative  concerned  the  overall  approach.  Here,  the  options  were: 

1.  Write  a completely  new  code  generator,  or 

2.  Create  new  modules  using  existing  code  generator  modules. 


CSC's  decision  was  to  use  the  existing  modules  as  a base  on  which  the  QCG  would 
be  built,  since  this  approach  (1)  would  yield  a code  generator  which  was  very  similar 
to  the  existing  code  generator,  (2)  would  save  considerable  time,  and  (3)  would 
simplify  maintenance,,  In  making  this  transformation,  several  previously-undetected 
errors  in  the  compiler  were  found  and  corrected. 

A second  major  consideration  concerned  the  handling  of  direct  code.  The  options 
considered  were: 

1.  Modifying  all  of  the  current  modules  which  handle  direct 
code  processing. 

2.  Prohibit  the  inclusion  of  direct  code  by  the  QCG. 

In  arriving  at  our  decision  to  prohibit  direct  code,  we  took  into  consideration  several 
factors: 

1.  In  any  retargetting  effort,  the  direct  code  must  be  rewritten 
for  the  target  machine  and  could,  therefore  be  called  as  an 
external  subroutine  instead  of  appearing  in  line. 

2.  The  existing  programs  which  process  the  IL  would  require 
modification  to  pass  source  code  through  to  the  QCG. 

3.  The  new  optimizer  under  concurrent  development  would  have 
been  impacted. 

4.  The  total  benefit  as  weighed  against  the  implementation  time  required 
was  minimal. 

The  QCG  contains  a set  of  predetermined  code  sequences  for  producing  frequently 
used  functions.  For  example,  the  JOVIAL  statement  A = B could  cause  a LOAD 
macro  and  a STORE  macro  to  be  generated.  The  code  sequences  are  table  driven 
and  register  dependent.  For  example,  given  the  statement  A = B + C,  if  either 
B or  C already  exists  in  a register  based  on  a previous  computation,  the  QCG 
recognizes  the  fact  and,  instead  of  loading  the  register,  uses  the  already  computed 
value  to  generate  the  ADD  and  STORE  instructions.  The  type  of  register  to  be  used 
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is  one  of  the  parameters  passed;  therefore,  only  one  sequence  exists,  and  it  is 
valid  for  integer,  single  precision,  and  double  precision  data.  This  single  code 
sequence  of  the  QCG  is  a departure  from  the  regular  code  generator  which  uses  a 
separate  set  of  sequences  for  integer,  single  precision,  and  double  precision  data. 
The  processing  of  character  data  is  also  slightly  different  from  the  regular  code 
generator.  The  MIMIC  language  does  not  provide  for  string  manipulation  macros 
and,  therefore,  all  character  data  is  handled  through  subroutine  calls  to  the  run- 
time library.  This  approach  required  that  a set  of  arguments  be  generated  to 
adequately  define  the  data  for  the  subroutine  so  that  the  subroutine  could  operate 
properly.  This  approach  was  taken  to  relieve  the  macro  writer  of  the  burden  of 
developing  string  handling  macros.  Such  macros  can  be  come  quite  complex  when 
implemented  on  word  oriented  hardware.  To  facilitate  the  retargetability  of  these 
subroutines,  they  were  written  in  JOVIAL.  The  regular  code  generator  produced 
in-line  code,  when  possible,  to  handle  character  data.  When  this  was  not  possible, 
subroutine  calls  were  generated. 

Near  the  end  of  the  project,  it  was  discovered  that  some  test  cases  would  not  com- 
pile correctly  through  the  ACG  if  the  Optimizer  was  requested.  Rather  than  spend 
the  short  time  remaining  on  solving  the  problem,  it  was  decided  that  optimization 
would  not  be  allowed  if  the  ACG  was  to  be  run.  The  two  major  reasons  for  this 
were:  first,  the  new  optimizer  being  developed  had  not  yet  been  interfaced  with  the 
ACG  and  similar  problems  would  likely  appear  there  as  well,  causing  further  delays 
in  the  project;  second,  given  the  limited  scope  of  use  of  the  ACG  (i.  e. , as  a "stop 
gap"  measure  during  the  writing  of  a target  machine  dependant  code  generator),  and 
given  the  limited  characteristics  of  the  hypothetical  machine  upon  which  MIMIC  is 
based,  optimization  would  have  little  or  no  major  affect  on  the  code  produced.  Ad- 
ditionally, the  quality  of  code  is  to  a great  extent,  dependent  upon  the  level  of  ex- 
pertise of  the  macro  writer. 


Because  of  its  more  general  design  the  yCG  generates  more  temporary  space  for  the 
computation  of  intermediate  results,,  The  management  of  this  space  is  critical  in 
keeping  the  size  of  this  temporary  space  to  a minimum.  Also,  failure  to  release 
temporary  space  when  no  longer  needed  often  results  in  compiler  errors,  incorrectly 
allocated  space,  or  both.  Persons  maintaining  this  compiler  must  be  aware  of  this 
critical  area  so  that  compiler  errors  are  not  introduced. 

MACRO  ASSEMBLER  PHASE 

The  MAS  phase  consists  of  two  levels:  a driver  for  the  MDE  procedures,  and  a 
group  of  utilities  to  serve  the  MDF  procedures.  The  driver  level,  after  initialization, 
reads  the  MIMIC  macros  from  the  Code  File  in  sequence  and,  tor  each,  invokes  the 
corresponding  MDF  procedure,  passing  the  MIMIC  operand  as  an  argument.  In  the 
initialization  step,  the  MDF  programmer  has  an  opportunity  to  specify  a number  of 
parameters  of  his  assembler,  e.g. , the  character  which  introduces  a comment,  the 
maximum  name  length,  etc.  This  information  will  be  used  by  the  MAS  utility  proce- 
dures. The  MDF  programmer  can  also  specify  the  order  in  which  he  wants  to  pro- 
cess the  various  segments  of  the  program,  such  as  code,  local  data,  external  declar- 
ations, etc. 

The  MAS  utilities  available  to  the  MDF  programmer  fall  into  three  groups.  The  first 
group  consists  of  editing  procedures  which  assist  him  in  building  Iris  output  lines  by 
performing  such  functions  as  adding  a string  of  characters  to  a partially  built  line, 
tabbing  to  a specified  position  in  a line,  and  outputting  a line  and  reinitializing.  These 
utilities  handle  most  of  the  work  of  character  manipulation  and  line  formatting. 

The  second  group  of  utilities  gives  the  MDF  programmer  access  to  information  in 
the  JOCIT  Symbol  Table,  such  as  the  allocated  size  of  an  item,  or  whether  or  not 
an  item  is  signed.  The  third  group  provides  such  miscellaneous  services  as  generat- 
ing unique  labels  for  use  if  local  branches  are  needed.in  the  assembly  code. 

The  MAS  also  provides  error  checking  to  assist  ir  ‘he  debugging  stage  of  a new  MDF. 
The  editing  utilities  detect  such  errors  as  runaway  line  length,  and  print  the  current 
output  line.  The  symbol  table  utilities  trap  an  invalid  symbol  table  pointer  and 

9 


i 


f 


identify  the  called  procedure.  An  error  limit  may  be  supplied  by  the  user,  to  stop 
processing  after  a specified  number  of  MAS  errors  have  been  detected. 

As  a test  of  the  system,  an  MDF  module  was  designed  and  implemented  to  produce 
code  for  the  current  host  machine.  A number  of  programs  were  compiled,  assembled 
by  GMAP,  and  successfully  executed.  However,  as  noted  later,  some  problems 
remain  even  with  this  "retargetting", 

A programmer  assigned  to  the  MDF  portion  of  a retargetting  effort  must  be  very 
familiar  with  his  target  machine,  its  assembler,  and  its  various  system  conventions. 
He  must  also  have  a working  knowledge  of  the  SYMPL  language,  in  which  he  will  be 
coding.  Then,  he  must  understand  the  meaning  and  intent  of  each  MIMIC  macro  and 
its  operand,  which  nuy  involve  some  understanding  of  JOVIAL  semantics  (although 
an  understanding  of  JOVIAL  syntax  is  not  required).  Finally,  he  must  become 
familiar  with  the  MAS  interface  and  the  various  utilities  at  his  disposal. 

The  other  major  effort  in  retargetting  JOCIT  is  converting  the  JOVIAL  Hun-Time 
Library.  Investigation  has  shown  that  the  non-l/O  library  modules  can  successfully 
be  written  in  JOVIAL,  and  thus  are  returgettable  like  any  other  program.  Simple 
machine  dependencies,  such  as  word  and  byte  size,  are  handled  bv  JOVIAL  DEFINE 
declarations,  and  must  be  changed  in  the  source  to  suit  the  target  machine  character- 
istics. However,  the  I/O  package  is  so  strongly  permeated  with  system  and  machine 
dependencies  that  it  requires  a complete  recoding  in  assembly  language  for  each  new- 
target. 

A number  of  problems  encountered  during  the  performance  of  the  work  remain  un- 
solved. This  situation  is  due  In  large  part  to  the  schedule  constraints,  and  the  fact 
that  several  other  JOCIT  enhancement  activities  were  going  on  concurrently,  some 
with  higher  priorities  than  the  ACG.  These  problems  were  mainly  in  the  area  of 
incompleteness  of  JOCIT  conversion. 

The  QCG  part  of  the  ACG  is  essentially  an  effort  to  retarget  the  JOCIT  code  generator 
to  the  hypothetical  MIMIC  machine.  To  a large  extent  this  was  successful.  However, 
the  interactions  between  the  code  generator  and  certain  other  non-essential  (but 
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certainly  useful)  compiler  functions  have  not  been  resolved.  Specifically,  the  QCG 
cannot  be  run  with  the  Optimizer,  nor  will  the  ACG  compiler  function  correctly  if 
a map  or  cross-reference  listing  is  requested.  Although  in  principle  it  should  be 
even  easier  to  handle  target  machine  DIRECT  code  when  the  compiler  itself  outputs 
assembly  language,  the  necessary  modifications  have  not  been  made,  and  the  ACG 
compiler  will  not  accept  DIRECT  code. 

Unfortunately,  a successful  retargetting  of  JOCIT  requires  more  than  Code  Generator 
work.  A specific  unsolved  problem  area  outside  the  scope  of  the  Code  Generator  is 
the  question  of  internal  data  representations.  The  current  ”front-end'’  of  the  compiler 
converts  numeric  constants,  such  as  preset  values,  to  Honeywell  machine  forms. 

On  the  one  hand,  this  seems  only  reasonable  if  the  compiler,  for  example,  is  to  do 
constant  arithmetic  on  the  host  machine.  On  the  other  hand,  however,  considerable 
difficulties  arise  in  the  MAS  and  MDF  in  trying  to  go  from  a Honeywell  bit  pattern 
to  a meaningful  source-language  constant  in  a foreign  assembly  language. 

Differences  in  word  size  may  also  invalidate  some  of  the  compiler's  host-oriented 
conversions  and  operations.  This  area  clearly  needs  much  investigation  to  produce 
a viable  solution. 

To  facilitate  retargetting  and  rehosting  efforts  in  the  future,  the  compiler  should  be 
carefully  examined  and  generalized  parameters  should  replace  all  machine  dependent 
values  currently  hard  coded  in  the  programs. 
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RADC  plans  and  conducts  research,  exploratory  and  advanced 
development  programs  In  command,  control,  and  communications 
(C3)  activities,  and  in  the  C3  areas  of  information  sciences 
and  Intelligence.  The  principal  technical  mission  areas 
are  communications , electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  objects,  intelligence 
data  collection  and  handling,  infortaatlon  system  technology , 
ionospheric  propagation,  solid  state  sciences,  mlcromave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


